Dynomotion

Group: DynoMotion Message: 2023 From: cell.vlad Date: 10/24/2011
Subject: Printer driver/interface for KFlop, question...
Recently I look on Laser CNC engravers and was very surprise, most of them simplify their CAM interface to some kind of driver (printer driver), which basically substitute all MACH_like or KMOTION_like interface to make parts, from CAD or vector driving, to Gcode, to machine, to physical part.
To make an part, you simply draw an vector or raster image in what ever software you like, and press Print; select a "output device" and can adjust an advanced setting, preview, and print. File goes to internal memory to their controller (ATMEGA128 + FPGA + Memory and IO) - ideologically similar to KFlop and from there goes to drivers and step motors...

My question: Did any one in the community thinking about, or perhaps it is already exist, about an printer like driver/interface for the KFlop?

I think it would be a great addition for the simple KFlop application for instance for the Laser cutter/engraver or even a complex one - like an mill or drill press. And by MHO it will great expansion for the KFlop usage.

Thank you for the share.

Vlad
Group: DynoMotion Message: 2024 From: brad murry Date: 10/24/2011
Subject: Re: Printer driver/interface for KFlop, question...
Vlad,
 
  With vector files you could easily parse them into line/arc/point segments and write gcode or feed directly to a coordmotion instance.  I suppose you could assign depths for simple milling operations via coloring or layers if there is a layer mechanism available in your vector format.  Otherwise you could manually set depths per image scan and build up complex parts with several files.
 
On rasters there are a few gotchas. I have built a point generator that takes a bitmap and processes depths based on pixel data much in the same way off the shelf artistic software works.  You need to filter/normalize the image and then convert it to gray-scale.  Then you define a min/max for Z and define a polarity vector(white is Z+ vs Z-).  Load this data in a collection and then you can output linear paths in any direction you choose.
 
I think the raster stuff is best suited to artistic engraving/carving applications as it is hard to achieve the precision needed for utilitarian parts.  You could add a "rules layer" on top of the raster interpreter that could recognize certain feature patterns and derive more accurate operations from the raw pixel data + rules.
 
 
I think a solid start to both of these scenarios could be realtively easy to acheive over a weekend or so using the Aforge.net imaging library and the Machine Manager framework.
 
 
 
Happy to help anyone interested in tackling this.
 

 -Brad Murry